Build: restore deleted files preserving history#11064
Build: restore deleted files preserving history#11064dmsnell wants to merge 23 commits intoWordPress:trunkfrom
Conversation
04cdca9 to
efc89d8
Compare
|
I have force-pushed from 04cdca9 to efc89d8, which is a big change:
|
5cfaf68 to
29b508c
Compare
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @1178653+wordpress-develop-pr-bot[bot]@users.noreply.github.com. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
ef9bcb2 to
4220ecc
Compare
See changelog in 474a396
The build change in #10638 removed many required files and added them to
.gitignore. This led to WordPress crashing when loadingwp-load.phpuntil thenom run build:devcommand was run.Deleting these files had a number of deleterious side-effects:
wordpress-develop, making it hard to see what code is going to run and hard to reference the files in places like Github wheregitCLI tools and the Gutenberg repo are not colocated and handy.git bisectto find root cause and changes containing the root cause.npm cihas to run, download more than 1 GB ofnpmpackages, and rebuild all of the files on everygit checkout. this practically eliminates the practicality of running workflows which assess the project over time.This PR brings back those files and connects them to their pre-build-change version history by branching from a point in
trunkimmediately before the build change.Although they were deleted in
trunk, this patch, when applied as a merge commit will provide two parents which will allow any and allgittooling to reconstruct the history of the files without any special options or flags.Status
This is ready for a full review.
As of the time of posting this, running
npm run grunt gutenberg:download -- --forcewith this branch checked out leaves no changes or ignored changes ingit, which suggests that every file which was changed has been accounted for.restored-file-history.mp4
Note:
svn-to-gitconversion. If the merge is lost in that process then it won’t matter if this PR restores the history, because it will be lost when back-writing from the Subversion source.Testing
Here is a sequence of events that simulates this operation. The script creates an SVN repo, adds some files and makes a few meaningless commits, then deletes a
test.txtfile.There is a
git svnmirror tracking the SVN repo.From the SVN side, a new branch is created to restore the files. It is forked from before they were deleted and then the
test.txtfile is modified in a neutral way so that it will create a merge conflict. This is important because otherwisesvnandgitwill automatically accept the deleted files as the truth.That branch is merged in which tracks the version history for the files, because it maintains metadata pointing to the commits before they were deleted.
On the
git svnside though it’s critical to firstgit svn fetch --allto retrieve the new branch (otherwise it will not have the metadata and therefore linearize the merge), and then to rungit rebase --merge --rebase-mergesso that it avoid linearizing the merge.simulating-restore.mp4